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(54) Node apparatus and method of using a virtual connection to transmit a pacl^et 



(57) A node manages a virtual.connection (VC) in a 
network such that at least one unused virtual connection 
to the neighboring node is established and registered. 
When a VC is needed to transmit a packet, the node 



obtains the required VC by selecting one of the regis- 
tered unused VCs instead of setting up a new VC. When 
a VC in use becomes no longer necessary, the node 
registers the VC as an unused VC instead of releasing 
the VC. 
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Description 
Background Art 

The present invention relates to network systems. 
More specifically, the invention relates to a node appa- 
ratus having an interface with a virtual-connection-ori- 
ented network and a method for managing a virtual con- 
nection to transmit packets from the node apparatus. 

To transfer packets through a virtual connection in 
a virtual-connection-oriented network, such as an ATM 
(Asynchronous Transfer Mode) network, a virtual con- 
nection is set up one of two ways: 

1 ) all virtual connections between nodes in the net- 
work are set up in advance of using the virtual con- 
nections to transfer packets (e.g., PVC (Permanent 
Virtual Connection) or VP (Virtual Path) in the ATM 
network); or 

2) an adequate virtual connection is set up when it 
is required in order to transfer packets, and it is re- 
leased when the transfer of packets terminates (e. 
g., SVC (Switched Virtual Connection) in the ATM 
network). 

The first method makes it possible to use a virtual 
connection without waiting for setup when a node is 
starting to transmit a packet. However a prior setup of 
all virtual connections by a human network manager has 
great difficulties. In addition, in the PVC method, it is dif- 
ficult to determine how many virtual connections to pre- 
set. In the VP method, the usage of virtual connections 
may be inefficient because many virtual connections of 
the fixed number (e.g., 2^^) are necessarily set up be- 
tween alt neighboring nodes. 

The second method sets up a virtual connection 
from a first node to a second node by, for example, ATM 
signaling when the first node is transmitting a packet to 
the second node, and releases the virtual connection by 
ATM signaling when the first node finishes transmitting 
packets to the second node. Because the setup of a vir- 
tual connection starts after the virtual connection be- 
comes necessary, a delay due to the setup exists until 
the node becomes able to transmit the packet. Moreo- 
ver the frequency of setup/release of virtual connec- 
tions is high because the virtual connection is released 
each time it becomes unnecessary. This require the 
highest performance nodes and switches in the network 
for in setup/release signaling. 

Disclosure of the Invention 

It is therefore an object of the present invention to 
provide a mechanism for obtaining a virtual connection 
with a smaller delay and with fewer setup/release ac- 
tions using signaling. 

A node consistent with this invention that is con- 
nected to a virtual-connection-oriented network com- 



prises VC means for setting up and releasing virtual con- 
nections with a neighboring node; means for transmit- 
ting a packet to the neighboring node through an estab- 
lished virtual connection; and means for controlling the 

5 VC means to maintain at least one virtual connection 
with the neighboring node not currently in use by the 
means for transmitting. 

A method consistent with this invention of managing 
a node connected to a virtual-connection-oriented net- 

10 work comprises the steps of setting up and releasing 
virtual connections with a neighboring node: transmit- 
ting a packet to the neighboring node through an estab- 
lished virtual connection: and maintaining at least one 
virtual connection with the neighboring node not current- 

'5 ly in use by the means for transmitting. 

Other features and advantage of the present inven- 
tion will be become apparent from the following descrip- 
tion taken in conjunction with the accompanying draw- 
ings. Both the foregoing general description and the fol- 

20 lowing detailed description provide examples consistent 
with this invention and explain how to make and use sys- 
tems and methods consistent with the invention. These 
description do not restrict the claimed invention. 

25 Brief Description of tiie Drawings 

Fig. 1 shows an exemplary network topology con- 
sistent with the present invention. 

Fig. 2 is a functional block diagram showing a con- 
30 figuration of a node in the network of Fig. 1 . 

Fig. 3 is a flowchart showing an operation for man- 
aging unused VCs. 

Fig. 4 shows sample contents of the unused VC ta- 
ble in Fig. 2. 

35 Fig. 5 is a flowchart showing an operation for ob- 
taining a virtual connection from a pool of unused VCs. 

Fig. 6 is a flowchart showing an operation for return- 
ing a VC to the pool of unused VCs. 

Fig. 7 shows an exemplary transition of the number 
40 of VCs. 

Fig. 8 shows another network topology consistent 
with the present invention. 

Fig. 9 is a functional block diagram showing a con- 
figuration of a node for the network in Fig. 8. 
^5 Fig. 1 0 shows sample contents of the IP routing ta- 
ble and the default VC table in Fig. 9. 

Best Mode for Carrying Out the Invention 

50 Now, the preferred embodiments according to the 
present invention will be described in detail. Though the 
following description involves an ATM network, the 
present invention can be practiced in another virtuai- 
connection-oriented network (e.g., frame relay) in a sim- 

55 jiar way as in the ATM network. 
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A. General Description 

A node consistent with the present invention has set 
up several VCs (e.g., SVCs) by ATM signaling in ad- 
vance, and has registered these VCs as unused VCs. 
When a VC beconnes necessary to transmit (transfer) a 
packet, the node obtains the required VC by selecting 
one of the registered unused VCs instead of setting up 
a new VC. When a VC in use becomes unnecessary 
because it is finished being used, the node registers the 
VC as an unused VC, instead of releasing the VC. 

The waiting time until a VC becomes usable can be 
shortened by eliminating the VC setup time, while sign- 
aling can still be used for setting up VCs. Also, more 
VCs than those currently being used for transmitting 
(transferring) packets can keep established, and the 
VCs can be reused so the frequency of setup/release of 
VCs by signaling and VC setup loads for nodes and 
switches in the network can be reduced. 

B. Example Operation 

An exemplary case of establishing VCs to transfer 
packets from node 101 A to node 101 B, C, or D in the 
network shown in Fig. 1 will be described. Node 101 A 
has interfaces (a) and (b). Interface (a) connects ATM 
switch 102 and ATM switch 102 connects node 101 B 
and C. Interface (b) connects node 101 D. Each connec- 
tion between nodes is implemented by ATM. A node can 
be either a router or a host. 

As shown in Fig. 2, node 101 A includes unused VC 
table 110, VC managing section 111, VC setup/release 
section 11 2, and packet transmitting (transferring) sec- 
tion 113. These sections can be implemented by either 
software or hardware. Node 101 A also includes one or 
more ATM l/F 1 1 4. For multiple l/Fs, the l/Fs can include 
one or more l/F other than ATM (e.g., Ethernet). 

Unused VC table 110 stores information of estab- 
lished VCs which are not in current use. The VCs reg- 
istered in unused VC table 110 constitute a pool of un- 
used VCs. VC managing section 111 obtains/returns a 
VC from/to unused VC table 110, in response to re- 
quests from packet transmitting (transferring) section 
113. VC managing section 111 also manages the 
number of unused VCs and controls VC setup/release 
section 112, such that the unused VCs the number of 
which is within a prescribed range exist. 

Fig. 3 shows an operation for managing unused 
VCs to form the pool of unused VCs. This operation is 
performed when a node is activated, when a VC is ob- 
tained from or returned to the pool, or periodically while 
a node is working. Nl in step S201 is the minimum 
number of unused VCs, and N2 in step S203 is the max- 
imum number of unused VCs. The operation results in 
keeping the number of unused VCs within a range from 
Nl to N2. 

Hereinafter, an example of Nl =1 , N2=3 will be tak- 
en for explanation. VC managing section 1 1 executes 



the flowchart of Fig. 3 for each neighboring node. A node 
can recognize which nodes are neighboring based on 
information preset by a human network manager or us- 
ing routing protocol automatically exchanged between 

5 nodes. The values of Nl and N2 can vary with individual 
neighboring nodes. 

VC managing section 111 compares the current 
number of unused VCs to a neighboring node in ques- 
tion with the minimum number Nl (S201 ). If that number 

10 issmallerthanNI (S201 Yes), VC managing section 111 
orders VC setup/release section 112 to set up one or 
more SVCs to the neighboring node through ATM sign- 
aling (S202). The number of VCs to be set up is deter- 
mined to maintain the number of unused VCs within a 

IS range of Nl to N2. When the setup is completed, VC 
managing section 1 1 1 registers information of the SVCs 
set up into unused VC table 110 as shown in Fig. 4. 

If the current number of unused VCs is N1 or more 
(S201 No), VC managing section 11 1 compares the cur- 

20 rent number of unused VCs with the maximum number 
N2 (S203). If that number is larger than N2 (S203 Yes), 
VC managing section 111 selects one or more unused 
VC to the neighboring node to be released referring to 
unused VC table 1 1 0, and orders VC setup/release sec- 

25 tion 1 1 2 to release the selected VC(s) through ATM sig- 
naling (S204), such that the number of unused VCs be- 
comes within a range of Nl to N2. If the current number 
of unused VCs is Nl or more and N2 or less (S203 No), 
no action is taken. 

30 When VC managing section 111 at node 101 A op- 
erates as described above in the network shown in Fig. 
1 , unused VC table 110 shown in Fig. 4 will be created. 
The table illustrates that there are 2,2, 1 unused VCs for 
neighboring nodes 101 B, C, D, respectively VCs of 1/ 

35 F=a, VPIA/CI=0/100 and l/F=a, VPI/VCI=0/101 are 
maintained as unused VCs to node B. VCs of l/F=a, VPI/ 
VCI-0/200 and l/F=a, VPI/VCI=0/201 are maintained as 
unused VCs to node C. A VC of l/F=b, VPI/VC1=0/100 
is maintained as unused VCs to node D. 

40 Fig. 5 shows an operation for obtaining a VC from 
the pool of unused VCs, for example, when node 101 A 
is starting to transmit (transfer) a packet to node B. 
Packet transmitting (transferring) section 113 requests 
VC managing section 111 to obtain a VC to a next-hop 

45 node B. VC managing section 111 , in response to this 
request, looks up the number of unused VCs and a 
pointer to VC information corresponding to the specified 
neighboring node's address (in this example, node B) in 
unused VC table 110 of Fig. 4 (S301 ). 

50 If the number of unused VCs is zero (S302 Yes), VC 
managing section 111 orders VC setup/release section 
1 1 2 to set up a new SVC (S305), and packet transmitting 
(transferring) section 113 uses this newly established 
SVC (S306). A situation where the number of unused 

55 VCs is zero might occur, for example, if the operation 
shown in Fig. 3 malfunctioned. 

If the number of unused VCs is not zero (S302 No), 
VC managing section 1 1 1 decrements the number of un- 
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used VCs in unused VC table 11 0 by (S303), and returns 
an l/F and a VPI/VCI written in an entry included in tlie 
list indicated by the VC pointer in unused VC table 110 
to packet transmitting (transferring) section 113 (3304). 
In this example, the number of unused VCs becomes 1 s 
and a VC of l/F=a, VPI/VCI=0/100 is picked up (deleted 
from unused VC table 110). Packet transmitting (trans- 
ferring) section 113 can use this selected VC without 
waiting for setup of a VC by signaling. 

VC managing section 111 returns a VC to unused 
VC table 110 when it is notified by packet transmitting 
(transferring) section 113 of a termination of use of the 
VC. as shown in the flowchart shown in Fig. 6. Specifi- 
cally, packet transmitting (transferring) section 113 no- 
tifies VC managing section 11 1 of the termination of use 
of a VC to a next-hop node B. In response to this 
notification ,VC managing section 111 looks up the 
number of unused VCs and a pointer to VC information 
corresponding to the specified neighboring node's ad- 
dress (in this example, node B) in unused VC table 110 

(5401) . VC managing section 111 increments the 
number of unused VCs in unused VC table 110 by 

(5402) , and adds an entry including l/F and VPIA/CI of 
the VC to be returned to the list indicated by the VC 
pointer in unused VC table 110 (S403). For example, 
when the VC of l/F=a, VPIA/CI=0/100 to node B is re- 
turned according to this operation, the contents of un- 
used VC table becomes as shown in Fig. 4 again. 

The operation for managing unused VCs shown in 
Fig. 3 can be executed periodically (as a background 
job) Independently of operations for obtaining/returning 
a VC shown In Figs. 5 and 6. Alternatively, the operation 
for managing unused VCs can be started, for example, 
each time after the number of unused VCs is changed 
by the operation of Fig. 5 or Fig. 6. 

The case where a node has set up several SVCs 
by ATM signaling in advance was described above. The 
present invention can also be practiced by the following 
embodiments: as a initial condition, several PVCs (the 
number can be determined arbitrarily within a range of 
N1 to N2) are set up between neighboring nodes. Then, 
when the number of VCs in current use increases and 
the number of unused PVCs decreases beyond N1 , the 
node sets up SVC(s) as in step S202. When the number 
of VCs in current use decreases and the total number 
of unused PVCs and SVCs increases beyond N2, the 
node releases SVC(s) until the total number becomes 
N2, as in step S204. In this case, the total number of 
unused PVCs and SVCs is treated as the number of un- 
used VCs. and both PVCs and SVCs constitute one pool 
of unused VCs. It may be preferable to choose a PVC 
if possible rather than a SVC when obtaining a VC from 
the pool to use it. 

As described above, a request for obtaining a VC 
is issued by packet transmitting (transferring) section 
1 1 3 when a new VC becomes necessary. Packet trans- 
mitting (transferring) section 113 issues the request 
when it needs a VC to transmit a packet but finds none 
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available. A router, for example, can issue the request 
when it finds no VC to be used to transfer a packet on 
receiving the packet. 

The VC sought to be used is a default VC to a next- 
hop node, in a network where an ordinary hop-by-hop 
packet transfer is performed. In this case, if the default 
VC does not exist, the request for obtaining a VC is is- 
sued. 

Alternatively, the VC sought to be used is a VC ded- 
icated to a specified packet flow to which the packet to 
be transmitted (transferred) belongs, and is in a network 
having a policy that a dedicated VC should be used to 
transmit (transfer) a packet belonging to a specified 
packet flow. The dedicated VC should not be used to 
transmit (transfer) a packet whose flow is other than the 
specified flow, even if the next -hop node is the same. In 
this case, if the dedicated VC for the specified flow does 
not exist, the request for obtaining a VC is issued. 

The packet belonging to the specified flow is a pack- 
et containing specified information. The specified infor- 
mation can be any one or combination of source IP (net- 
work-layer) address, destination IP address, IP address 
prefix, port number of transport-layer, identifier of proto- 
col whose layer is higher than the transport-layer, and 
flow ID of IPv6. 

Packet transmitting (transferring) section 113 can 
also issue a request for obtaining a VC when a new VC 
is requested by protocol exchanged between neighbor- 
ing nodes. For example, it can issue the request on re- 
ceiving a Path or Resv message of RSVP (Resource 
reservation Protocol), based on the message. Here, if 
the protocol specifies a packet flow, a VC dedicated to 
the specified flow will be requested. 

On the other hand, a request for returning a VC is 
issued by packet transmitting (transferring) section 113 
when the VC becomes unnecessary. Packet transmit- 
ting (transferring) section 113 can issue the request 
when it has not transmitted a packet through that VC for 
a prescribed period, or when it is requested to release 
that VC by another node with some protocol. 

One of the effects of the present embodiments is 
that the VC setup loads for nodes and switches can be 
reduced. Fig. 7 is a diagram that explains this effect con- 
ceptually. The frequency of setup/release of VCs by sig- 
naling becomes the times of increase and decrease of 
the number of VCs in use (thin line) according to the 
conventional SVC method, while the frequency is re- 
duced to the times of increase and decrease of the 
number of established VCs (bold line) according to the 
present method. 

C. Implementation in a Cell Switched Router (CSR) 
Case 

CSR (Cell Switched Router) is a router that can 
transfer packets on cell-by-cell basis using ATM switch- 
es, and can transfer packets by network-layer (e g., IP) 
forwarding. Cell-by-cell transfer may be called cut- 
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through transfer or datalink-layer transfer. Using ATM 
switch in a router at a boundary between logical net- 
works (e.g., IP subnets) makes it possible to transfer 
packets with high-throughput and low-latency in an in- 
ter-network environnnent. 

Specifically, each CSR on the route of a certain 
communication performs hop-by-hop IP forwarding by 
assembling received cells to a packet and analyzing a 
destination IP address, while each CSR on the route of 
a certain (specified) communication performs cell-by- 
cell transfer, bypassing IP processing, by referring to a 
virtual connection Identifier (e.g., VPI/VCI) in a received 
cell. 

A VC used for transferring packets to be processed 
hop-by-hop is a default VC. A VC used for transferring 
packets to be processed on cell-by-cell basis even at a 
router (CSR) Is a dedicated VC. The dedicated VCs are 
prepared for respective specified communications, be- 
cause a router cannot see the contents of IP packets 
and can recognize which communication a received cell 
is only by a virtual connection identifier when transfer- 
ring on cell-by-ceil basis. For example, each dedicated 
VC is used to transfer packets to each corresponding 
destination network or destination host. 

Fig. 8 shows an exemplary network topology In 
which CSR technology is applied. Packets destined to 
node H2 are transferred hop-by-hop through a default 
VC from R1 to R2 and from R2 to H2. VCs dedicated to 
a communication to destination host H3 are set up not 
only between R2 and H3, but also between R1 and R2. 
VCs dedicated to a communication to destination host 
H4 are set up not only between R2 and R3 but also R1 
and R2. Thus, from R1 to R2, a plurality of dedicated 
VCs exist, each of which is dedicated to each specified 
communication flow. 

A new cell-by-cetl transfer from R1 through R2 to a 
new node H5 may require one more dedicated VC from 
R1 to R2. Consequently, to one neighboring node (e.g., 
from R1 to R2), several VCs are required and set up/ 
released. Preserving a prescribed number of spare VCs 
according to the present invention will be effective es- 
pecially in such a situation. 

Fig. 9 shows an exemplary configuration of a node 
(R1 ) for performing the present method. One difference 
from the node shown In Fig. 2 is that In the node shown 
In Fig. 9, packet transmitting (transferring) section 113 
operates referring to default VC table 115 and IP routing 
table 116. Fig. 10 shows exemplary contents of these 
tables. 

On transmitting (transferring) a packet, packet 
transmitting (transferring) section 113 searches IP rout- 
ing table 116 using a destination address included in a 
packet to be transmitted (transferred) as a key. When 
the packet is to be transferred hop-by-hop, section 113 
finds an l/F and a next-hop address (R2), and then 
searches default VC table 115 using the next-hop ad- 
dress as a key. Then, section 113 finds that It should use 
a VC of VPI/VCI=0/100 (a default VC to next-hop R2) to 



transmit (transfer) the packet destined to H2. If R1 has 
a packet to be transferred through R2 to a new node H6 
hop-by-hop. section 113 of Rl will find the same next- 
hop address (R2) and the same VC (VP1A/CI=0/1 00) to 
5 be used. 

When the packet is to be transferred cell-by-cell, 
section 113 finds an l/F and a VPI/VCI. Thus, section 
113 finds that it should use a VC of VPIA/Cl =0/200 (a 
dedicated VC to destination H3) to transmit (transfer) a 

10 packet destined to H3, or finds that it should use a VC 
of VPI/VCI=0/300 (a dedicated VC to destination H4) to 
transmit (transfer) a packet destined to H4. 

On adding a new entry to IP routing table 116, a 
node has to obtain a VC. For example, assume a VC 

IS dedicated to destination H4 becomes necessary and no 
entry of destination address H4 (or no VPI/VCI In the 
entry of destination address H4) is written in IP routing 
table. Packet transmitting (transferring) section 113 can 
recognize that the dedicated VC to destination H4 be- 

20 comes necessary when examining contents of a packet 
to be transmitted (or a packet received) destined to H4, 
or when exchanging protocol from/to a neighboring 
node In advance of performing cell-by-cell transfer (e. 
g., FANP (Flow Attribute Notification Protocol). 

25 Packet transmitting (transferring) section 113 is- 
sues a request for obtaining a VC to R2 to VC managing 
section 111 , when recognizing that the dedicated VC to 
H4 becomes necessary. VC managing section 1 1 1 is op- 
erating according to Figs. 3, 5 and 6, and selects a de- 

30 sired VC f ronn unused VC table 1 1 0 to return l/F and VPI/ 
VCI of the selected VC to packet transmitting (transfer- 
ring) section 113. Packet transmitting (transferring) sec- 
tion 1 1 3 registers the returned l/F and VPf/VCI In IP rout- 
ing table 116 as a dedicated VC to destination H4. VC 

35 managing section 1 1 1 treats a VC that Is not registered 
In default VC table 115 or IP routing table 116 as an un- 
used VC. 

If, for example, a dedicated VC to destination H3 
becomes unnecessary, packet transmitting (transfer- 
ee ring) section 113 deletes VPt/VCl of the dedicated VC 
from the entry of destination address H3 (and instead 
writes next-hop address R2) and notifies VC managing 
section 111 of termination of using the dedicated VC. 
VC managing section 111 returns l/F=b, VPI/VCl=0/200 
•*5 to unused VC table 1 1 0 as an unused VC to neighboring 
node R2. 

In this example, a dedicated VC for each specified 
"destination" Is used. The node can also operate in a 
similar way, however, in a case of using a dedicated VC 

50 for each specified "packet flow" whose example was 
shown in the previous embodiment. 

R2 in the above example may be a router that does 
not perform cell-by-cell basis transfer but applies a cer- 
tain specified processing to a packet belonging to a 

55 specified flow. Specifically, Rl sends packets belonging 
to a specified flow through a dedicated VC, and then R2 
can know the flow of a received packet from the VC iden- 
tifier and, for example, can give a higher priority in trans- 
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fer scheduling to the received packet belonging to the 
specified flow. In such a situation also, forming a pool 
of spare VCs according to the present invention will be 
effective because quite a few VCs to one neighboring 
node becomes necessary/unnecessary frequently. 

In the above embodiments, it may be desirable to 
relate a VC to a specified flow by both ends of the VC. 
To perform that, it is preferable to give the VC an iden- 
tifier that can be uniquely identified by both ends of the 
VC. However, if an ATM switch exists between neigh- 
boring nodes (e.g., 102 in Fig. 1) and a SVC is set up 
through the switch, a value of VPIA/Cl of the SVC will 
be changed at the switch, not the same at individual 
neighboring nodes. Thus, the unique identifier (different 
from VPIA/CI) of the SVC may be determined by mes- 
sage exchange between the neighboring nodes. In such 
a case, it is possible to give the unique identifier to a VC 
on setting it up at step 8202 of Fig. 3 and to register the 
unique identifier in unused VC table 110 in addition to 1/ 
F. VPI/VCI. When a new VC becomes necessary, the 
unique identifier of a selected VC may also be returned 
at S304 of Fig. 5. 

In addition to those already mentioned above, per- 
sons of ordinary skill will realize that many modifications 
and variations of the above embodiments may be made 
without departing from the novel and advantageous fea- 
tures of the present invention. 

For example, an embodiment according to the 
present invention where NHRP (Next-Hop Resolution 
Protocol) is available will be considered. NHRP is used 
for inquiring of a route server about a destination IP ad- 
dress, obtaining a link address (e.g., ATM address) of 
the destination or a router closest to the destination from 
the server, and setting up a virtual connection to the des- 
tination or the closest router based on the link address. 
Treating this link address as the neighboring node ad- 
dress in the above-mentioned embodiments makes it 
possible to keep a prescribed number of spare VC(s) 
existing for immediate use. 

Accordingly, all such modifications and variations 
are intended to be included within the scope of the ap- 
pended claims. The embodiments in the specification 
are only exemplary. The following claims define the true 
scope and sprit of the invention. 



Claims 

1 . A node, connected to a virtual-connection-oriented 
network, comprising: 



boring node that is not currently in use by the 
means for transmitting. 

2. The node according to claim 1 , wherein the means 
5 for controlling includes: 

means for detecting the number of virtual con- 
nections with the neighboring node not in use 
by the means for transmitting; and 
10 means for causing the VC means to set up or 

release a virtual connection with the neighbor- 
ing node based on the detected number of vir- 
tual connections. 

15 3. The node according to claim 1 . further comprising 
a memory, coupled to the VC means, for stor- 
ing information about virtual connections with the 
neighboring node that are not currently in use by 
the means for transmitting. 

20 

4. The node according to claim 3, wherein the means 
for transmitting includes: 

means for determining the necessity of a virtual 
^5 connection to transmit the packet; and 

means for changing the state of the virtual con- 
nection according to the means for determining 
by referring to the memory. 

30 5. The node according to. claim 1. wherein the VC 
means includes 

means for performing signaling to set up or 
release the virtual connection. 

55 6. The node according to claim 1 , wherein the means 
for transmitting includes 

means for transmitting the packet through one 
of the virtual connections set up by the VC means. 

-io 7. The node according to claim 6, wherein the means 
for transmitting further includes 

means for transmitting the packet through a 
preset permanent virtual connection. 

-45 8. The node according to claim 3, wherein the memory 
includes 

a portion for storing an identifier for each vir- 
tual connection, the identifier uniquely identifying 
the virtual connection between the neighboring 
so node and the node. 

9. The node according to claim 4, wherein the means 
for determining includes 

means for determining the necessity of a vir- 



VC means for setting up or releasing a virtual 
connection with a neighboring node; 
means for transmitting a packet to the neigh- 
boring node through an established virtual con- 
nection; and 

means for controlling the VC means to maintain 
at least one virtual connection with the neigh- 



15 



20 



55 tual connection dedicated to a specified flow to 
transmit the packet belonging to the specified flow 

10. A node, connected to a virtual-connection-oriented 
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network, comprising: 

a first section configured to set up or release a 

virtual connection with a neighboring node; 

a second section configured to transnait a pack- s 

et through an established virtual connection; 

and 

a third section configured to control the first 
section to nnaintain at least one virtual connec- 
tion with the neighboring node that is not cur- 
rently in use by the second section. 

11. A node, connected to a virtual-connection-oriented 
network, comprising; 

15 

\IC means for setting up or releasing a virtual 
connection with a neighboring node; 
a memory, coupled to the VC means, for storing 
information about a first virtual connection 
available for transferring a packet to be trans- 
mitted to the neighboring node and about a sec- 
ond virtual connection dedicated to transfer of 
a packet belonging to a specified flow and to be 
transmitted to the neighboring node; 
means for determining whether to transmit a 25 
packet through the first or second virtual con- 
nection by referring to the memory; 
means for transmitting a packet through the de- 
termined virtual connection: and 
means for controlling the VC means to maintain 3o 
at least one unused virtual connection with the 
neighboring node capable of being dedicated 
to a new specified flow. 

1 2. A method of managing a virtual connection in a net- 35 
work, comprising the steps of: 

maintaining an established and unused virtual 
connection between neighboring nodes in a 
network: 

setting up a new virtual connection between the 
neighboring nodes when the number of unused 
virtual connections between the nodes is less 
than a first predetermined number: and 
releasing one of the established and unused -^s 
virtual connection between the neighboring 
nodes when the number of unused virtual con- 
nections between the nodes exceeds a second 
predetermined number. 

so 

1 3. The method according to claim 1 2, further compris- 
ing the steps of: 

obtaining one of the established and unused 
virtual connection as a new virtual connection 55 
when a new virtual connection between the 
neighboring nodes becomes necessary to 
transmit a packet: and 



returning the obtained virtual connection as an 
established and unused virtual connection 
when the obtained virtual connection finishes 
being used to transmit a packet. 

1 4. The method according to claim 1 3, wherein the step 
of obtaining includes the steps of: 

examining a new packet received or to be trans- 
mitted: and 

determining that the new virtual connection be- 
comes necessary when a virtual connection to 
be used to transmit the new packet does not 
exist. 

15. The method according to claim 13, wherein the step 
of obtaining includes the step of 

determining that the new virtual connection 
becomes necessary when the new virtual connec- 
tion is required by a protocol message. 

16. The method according to claim 13, wherein the step 
of returning includes the step of 

determining that the established virtual con- 
nection finishes being used when no packet is 
transmitted through the established virtual connec- 
tion for a prescribed period of time. 

17. The method according to claim 13, wherein the step 
of returning includes the step of 

determining that the established virtual con- 
nection finishes being used when release of the es- 
tablished virtual connection is required by a protocol 
message. 

1 8. The method according to claim 1 3, wherein the step 
of obtaining includes the step of 

determining that the new virtual connection 
becomes necessary when a virtual connection ded- 
icated to transfer of a packet belonging to a speci- 
fied flow does not exist. 

19. The method according to claim 13, further compris- 
ing the steps of: 

examining a message indicating an identifier of 
the virtual connection the identifier uniquely 
identifying the virtual connection between the 
neighboring nodes; and 
storing the identifier of the established virtual 
connection indicated by the message prior to 
obtaining the virtual connection. 

20. The method according to claim 13, wherein the 
steps of setting up and releasing are executed in- 
dependently of executing the steps of obtaining and 
keeping. 
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21. The method according to claim 13, wherein the 
steps of setting up and releasing are executed after 
executing the steps of obtaining and keeping. 

22. A method of managing a virtual connection in a net- s 
work, comprising the steps of: 

setting up at least one new virtual connection 
to maintain at least one unused virtual connec- 
tion to a neighboring node capable of being io 
dedicated to transfer of a packet belonging to 
a new specified flow; 

storing information of a first virtual connection 
available for transferring a packet to be trans- 
mitted to the neighboring node: '5 
storing information of a second virtual connec- 
tion dedicated to a specified flow, the second 
virtual connection being selected from the es- 
tablished and unused virtual connection when 
the second virtual connection becomes neces- 20 
sary to transmit a packet belonging to the spec- 
ified flow: and 

transmitting a packet through the first or second 
virtual connection, referring to the stored infor- 
mation. 2S 

23. A method of managing node connected to a virtual- 
connection-oriented network, comprising the steps 
of: 

30 

setting up and releasing a virtual connection 
with a neighboring node: 
transmitting a packet to the neighboring node 
through an established virtual connection; and 
controlling the VC means to maintain at least 35 
one virtual connection with the neighboring 
node not currently in use for transmitting. 

24. A network of nodes, wherein each of the nodes 
comprises: ^0 

VC means for setting up or releasing a virtual 
connection with a neighboring node: 
means for transmitting a packet to the neigh- 
boring node through an established virtual con- -^5 
nection; and 

means for controlling the VC means to maintain 
at least one virtual connection with the neigh- 
boring node not currently in use by the means 
for transmitting. so 
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